NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/2617

Text File | 1996-08-06 | 13.0 KB | 344 lines

Path: Portugal.EU.net!alce!Joe.Buck
From: [e-mail] (Joe Buck)
Newsgroups: comp.lang.c++
Subject: (2/2) FAQ for g++ and libg++, texinfo version [Revised 15 Jan 1996]
Message-ID: <[e-mail]>
Date: Mon, 15 Jan 96 14:00:11 GMT
Organization: Associacao Lusa de Correio Electronico

You may be running into a bug that was introduced in version 2.6.1
(and is still present in 2.6.3) that generated external linkage
for templates even when neither @code{-fexternal-templates} nor
@code{-fno-implicit-templates} is specified.  There is a patch for
this problem at @*
@file{ftp://ftp.cygnus.com/pub/g++/gcc-2.6.3-template-fix}.

I recommend either applying the patch or
using @code{-fno-implicit-templates}
together with explicit template instantiation as described in previous
sections.

This bug is fixed in 2.7.0.

@node Standard Template Library, agreement with standards, redundant
templates, User Problems
@section Does g++ support the Standard Template Library?

From Per Bothner:

@cindex STL
@cindex Standard Template Library
The Standard Template Library (STL) uses many of the extensions that the
ANSI/ISO committee has made to templates, and g++ doesn't support
some of these yet.  So if you grab HP's free implementation of STL it
isn't going to work.  However, libg++-2.6.2 contains a
hacked version of STL, based on work by Carsten Bormann, which permits
gcc-2.6.3 to compile at least the containers.  A full implementation is
going to need improved template support, which will take a while yet.

As of libg++-2.7.0 and gcc-2.7.0, I've succeeded in making many short
STL example programs work, though there are still a number of bugs
and limitations.  Almost all of the ObjectSpace examples (a set of
over 200 simple examples of STL usage) now work.

There are several commercial suppliers of STL implementations;
ObjectSpace's version supports gcc-2.7.x.

Mumit Khan has produced an ``STL newbie guide'' with lots of information
on using STL with gcc.  See

@file{http://www.xraylith.wisc.edu/~khan/software/stl/STL.newbie.html}

@node agreement with standards, compiling standard libraries, Standard
Template Library, User Problems
@section What are the differences between g++ and the ARM specification of
C++?

@cindex ARM [Annotated C++ Ref Manual]
@cindex exceptions
As of version 2.7.0, g++ has exception support on most but not all
platforms
(no support on MIPS-based platforms yet), but
it doesn't work right if optimizaton is enabled, which means the
exception
implementation is still
not really ready for production use.


@cindex mutable
Some features that the ANSI/ISO standardization committee has voted in
that don't appear in the ARM are supported, notably the @code{mutable}
keyword, in version 2.5.x.  2.6.x adds support for the built-in boolean
type @code{bool}, with constants @code{true} and @code{false}.  The
beginnings of run-time type identification are present, so there are
more reserved words: @code{typeid}, @code{static_cast},
@code{reinterpret_cast}, @code{const_cast}, and @code{dynamic_cast}.

@cindex g++ bugs
As with any beta-test compiler, there are bugs.  You can help improve
the compiler by submitting detailed bug reports.

One of the weakest areas of g++ other than templates is the resolution
of overloaded functions and operators in complex cases.  The usual
symptom is that in a case where the ARM says that it is ambiguous which
function should be chosen, g++ chooses one (often the first one
declared).  This is usually not a problem when porting C++ code from
other compilers to g++, but shows up as errors when code developed under
g++ is ported to other compilers.  (I believe this is no longer a
significant problem in 2.7.0).

[A full bug list would be very long indeed, so I won't put one here.
I may add a list of frequently-reported bugs and "non-bugs" like the
static class members issue mentioned above].

@node compiling standard libraries, debugging on SVR4 systems, agreement
with standards, User Problems
@section Will g++ compile InterViews?  The NIH class library?  Rogue Wave?

@cindex NIH class library
@cindex NIHCL with g++
The NIH class library uses a non-portable, compiler-dependent hack
to initialize itself, which makes life difficult for g++ users.
It will not work without modification, and I don't know what modifications
are required or whether anyone has done them successfully.

In short, it's not going to happen any time soon (previous FAQs referred
to patches that a new NIHCL release would hopefully contain, but this
hasn't happened).

@strong{Note:} I thought I saw an item indicating that someone
@emph{had} patched NIHCL to work with g++.  Any pointers?

@cindex InterViews
I think that as of version 2.5.6, the standard g++ will compile the
standard 3.1 InterViews completely successfully.
Note that you'll need the @code{-fno-for-scope} flag
if you use gcc-2.7.0; with 2.7.2 you may be able to omit this flag
but you'll get warnings.

@cindex Rogue Wave
According to Jason Merrill, the latest g++ (2.7.0) works with Rogue
Wave's @code{tools.h++} class library, but you may want to grab
@file{ftp://ftp.cygnus.com/pub/g++/Tools.h++-6.1-patch}.  Again,
you'll need the @code{-fno-for-scope} flag since Rogue Wave hasn't
fixed their code to comply with the new standard yet.

@node debugging on SVR4 systems, X11 conflicts with libg++, compiling
standard libraries, User Problems
@section Debugging on SVR4 systems
@cindex System VR4, debugging

``How do I get debugging to work on my System V Release 4 system?''

Most systems based on System V Release 4 (except Solaris) encode symbolic
debugging information in a format known as `DWARF'.

Although the GNU C compiler already knows how to write out symbolic
debugging
information in the DWARF format, the GNU C++ compiler does not yet have
this
feature, nor is it likely to in the immediate future.

Ron Guilmette has done a great deal of work to try to get the GNU C++
compiler
to produce DWARF format symbolic debugging information (for C++ code)
but he gave up on the project because of a lack of funding and/or interest
from the g++ user community.  If you have a strong desire to see this
project
completed, contact Ron at <rfg@@netcom.com>.

In the meantime, you @emph{can} get g++ debugging under SVR4 systems by
configuring gcc with the @code{--with-stabs} option.  This causes gcc to
use an alternate debugging format, one more like that used under SunOS4.
You won't need to do anything special to GDB; it will always understand
the ``stabs'' format.

@node X11 conflicts with libg++, assignment to streams, debugging on SVR4
systems, User Problems
@section X11 conflicts with libg++ in definition of String
@cindex String, conflicts in definition

``X11 and Motif define String, and this conflicts with the String class
in libg++.  How can I use both together?''

One possible method is the following:

@example
#define String XString
#include <X11/Intrinsic.h>
/* include other X11 and Motif headers */
#undef String
@end example

and remember to use the correct @code{String} or @code{XString} when
you declare things later.

@node assignment to streams, ,X11 conflicts with libg++, User Problems
@section Why can't I assign one stream to another?

[ Thanks to Per Bothner and Jerry Schwarz for this section. ]

Assigning one stream to another seems like a reasonable thing to do, but
it's a bad idea.  Usually, this comes up because people want to assign
to @code{cout}.  This is poor style, especially for libraries, and is
contrary to good object-oriented design.  (Libraries that write directly
to @code{cout} are less flexible, modular, and object-oriented).

The iostream classes do not allow assigning to arbitrary streams, because
this can violate typing:

@example
ifstream foo ("foo");
istrstream str(...);
foo = str;
foo->close ();  /* Oops! Not defined for istrstream! */
@end example

@cindex assignment to cout

The original cfront implementation of iostreams by Jerry Schwarz allows
you to assign to @code{cin}, @code{cout}, @code{cerr}, and @code{clog},
but this is not part of the draft standard for iostreams and generally
isn't considered a good idea, so standard-conforming code shouldn't use
this technique.

The GNU implementation of iostream did not support assigning to
@code{cin}, @code{cout}, @code{cerr}, and @code{clog}
for quite a while, but it now does, for backward
compatibility with cfront iostream (versions 2.6.1 and later of libg++).

The ANSI/ISO C++ Working Paper does provide ways of changing the
streambuf associated with a stream.  Assignment isn't allowed;
there is an explicit named member that must be used.

However, it is not wise to do this, and the results are confusing.  For
example: @code{fstream::rdbuf} is supposed to return the @emph{original}
filebuf, not the one you assigned. (This is not yet implemented in GNU
iostream.)  This must be so because @code{fstream::rdbuf} is defined to
return a @code{filebuf *}.

@node legalities, index, User Problems, Top
@chapter What are the rules for shipping code built with g++ and libg++?
@cindex Shipping rules
@cindex GPL [GNU Public License]

``Is it is possible to distribute programs for profit that are created
with g++ and use the g++ libraries?''

I am not a lawyer, and this is not legal advice.  In any case, I have
little interest in telling people how to violate the spirit of the
GNU licenses without violating the letter.  This section tells you
how to comply with the intention of the GNU licenses as best I understand
them.

@cindex FSF [Free Software Foundation]
The FSF has no objection to your making money.  Its only interest is that
source code to their programs, and libraries, and to modified versions of
their programs and libraries, is always available.

The short answer is that you do not need to release the source to
your program, but you can't just ship a stripped executable either,
unless you use only the subset of libg++ that includes the iostreams
classes (see discussion below) or the new libstdc++ library (available
in libg++ 2.6.2 and later).

Compiling your code with a GNU compiler does not affect its copyright;
it is still yours.  However, in order to ship code that links in a GNU
library such as libg++ there are certain rules you must follow.  The
rules are described in the file COPYING.LIB that accompanies gcc
distributions; it is also included in the libg++ distribution.
See that file for the exact rules.  The agreement is called the
Library GNU Public License or LGPL.  It is much "looser" than the
GNU Public License, or GPL, that covers must GNU programs.

@cindex libg++, shipping code
Here's the deal: let's say that you use some version of libg++,
completely unchanged, in your software, and you want to ship only
a binary form of your code.  You can do this, but there are several
special requirements.  If you want to use libg++ but ship only object
code for your code, you have to ship source for libg++ (or ensure
somehow that your customer already has the source for the exact
version you are using), and ship your application in linkable form.
You cannot forbid your customer from reverse-engineering or extending
your program by exploiting its linkable form.

@cindex libg++, modifying
Furthermore, if you modify libg++ itself, you must provide source
for your modifications (making a derived class does not count as
modifying the library -- that is "a work that uses the library").

@cindex special copying conditions for iostreams
For certain portions of libg++ that implement required parts of the C++
language (such as iostreams and other standard classes), the FSF has
loosened the copyright requirement still more by adding the ``special
exception'' clause, which reads as follows:

@quotation
As a special exception, if you link this library with files
compiled with GCC to produce an executable, this does not cause
the resulting executable to be covered by the GNU General Public License.
This exception does not however invalidate any other reasons why
the extion I get undefined symbols when using templates

(Thanks to Jason Merrill for this section).

@cindex template instantiation
g++ does not automatically instantiate templates defined in other files.
Because of this, code written for cfront will often produce undefined
symbol errors when compiled with g++.  You need to tell g++ which template
instances you want, by explicitly instantiating them in the file where
they
are defined.  For instance, given the files

@file{templates.h}:
@example
template <class T>
class A @{
public:
  void f ();
  T t;
@};

template <class T> void g (T a);
@end example

@file{templates.cc}:
@example
#include "templates.h"

template <class T>
void A<T>::f () @{ @}

template <class T>
void g (T a) @{ @}
@end example


main.cc:
@example
#include "templates.h"

main ()
@{
  A<int> a;
  a.f ();
  g (a);
@}
@end example

compiling everything with @code{g++ main.cc templates.cc} will result in
undefined symbol errors for @samp{A<int>::f ()} and @samp{g (A<int>)}.  To
fix these errors, add the lines

@example
template class A<int>;
template void g (A<int>);
@end example

to the bottom of @samp{templates.cc} and recompile.

@node redundant templates, Standard Template Library, undefined templates,
User Problems
@section I get multiply defined symbols using templates